.github/workflows/unassign-stale-issues.yml (3)

49-50: Broaden PR-link detection beyond the connected event

Some issues are linked to PRs via a cross-reference (cross-referenced) rather than the “connected” event (e.g., using “Fixes #123” in the PR body).
Limiting the search to event === 'connected' may yield false negatives and trigger unwarranted unassignments.

-const prLinkedEvent = timeline.find(e => e.event === 'connected');
+const prLinkedEvent = timeline.find(e =>
+  e.event === 'connected' || e.event === 'cross-referenced');

Consider also checking event.source.issue.pull_request to confirm the reference is indeed a PR.

---

59-60: Guard-rail: treat “exactly 7 days” as within the grace period

The comparison prLinkedAt > assignedAt + 7 days excludes PRs linked exactly at the 7-day mark, which users may perceive as being “on time”.
Switch to >= when computing the unassignment threshold to make the rule inclusive and simpler to explain.

-if (!prLinkedAt || prLinkedAt > new Date(assignedAt.getTime() + daysBeforeUnassign*24*60*60*1000)) {
+if (!prLinkedAt || prLinkedAt >= new Date(assignedAt.getTime() + daysBeforeUnassign*24*60*60*1000)) {

---

22-38: Potential rate-limit hotspot

For every open, assigned issue you paginate all timeline events.
On large repos this can hit secondary rate limits quickly.
Two optimisations:

1. Stop paginating once both a relevant assignment and PR-link event have been found.
2. Switch to a GraphQL query that requests only assigned, unassigned, connected, and cross-referenced events in a single round-trip.

Not urgent, but worth scheduling before repo traffic grows.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

.github/workflows/unassign-stale-issues.yml (3)

39-41: Comment wording contradicts the code

The inline comment says “Find the first assignment event date” but the code deliberately takes the latest assignment (.at(-1)).
Update the comment to avoid confusion for future maintainers.

---

31-37: Potential rate-limit hit when paginating per-issue timelines

listEventsForTimeline is invoked for every open, assigned issue.
On repositories with hundreds of assigned issues this can exceed REST rate limits and slow the workflow.

Consider batching with GraphQL (search/issues, timeline items) or limiting the call set by first filtering issues whose updated_at is older than the 7-day window.

---

56-58: Minor: avoid recomputing the 7-day threshold in the hot path

The expression creating a new Date inside the inner if allocates once per issue.
Calculate const unassignThreshold = new Date(assignedAt.getTime() + daysBeforeUnassign * 864e5); once and reuse it to make the intent clearer and shave allocations.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

.github/workflows/unassign-stale-issues.yml (2)

39-41: Update comment to reflect “latest” assignment, not “first”.

The code now correctly selects the last assignment event (.at(-1)), but the inline comment still says “first assignment event date”.
This can easily mislead future maintainers.

-// Find the first assignment event date
+// Find the most recent assignment event date

---

31-37: Potential rate-limit risk when paging every issue’s full timeline.

listEventsForTimeline is invoked for every open, assigned issue; each call may need several paginated requests.
In repos with hundreds of active issues this easily consumes the REST API rate limit, causing the job to fail midway.

Consider:
• Filtering candidate issues first by since: (e.g. updated:<now-8d) to reduce the set.
• Using the GraphQL API to batch-fetch only assigned/cross-referenced events for multiple issues in one round-trip.

This keeps the job within rate limits while scaling.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro